Decouple engine from UI #189
Conversation
…es the widget, and a plugin which creates the command and button(s).
|
That sounds really interesting and i think if entity_embed wants to offer nice helpers for all use cases we need this kind of separation. |
|
Great work! I agree with @mirodietiker. This change makes a lot of sense. I gave it a quick sanity check only as I don't have time to do a proper review ATM. I hope me or somebody else comes back to properly review and test asap. |
|
👍 |
|
This is great - and likely a common use case. +1 |
|
Please, I'd love to review this as well. |
| @@ -8,7 +8,6 @@ | |||
| namespace Drupal\entity_embed\Plugin\CKEditorPlugin; | |||
|
|
|||
| use Drupal\editor\Entity\Editor; | |||
| use Drupal\embed\EmbedButtonInterface; | |||
| use Drupal\embed\EmbedCKEditorPluginBase; | |||
There was a problem hiding this comment.
Seems odd that this would still extend EmbedCKEditorPluginBase?
|
I tested this PR and it seems to breaks CKEditor. Could we convert "engine" into a JS library? Would this allow us to use it in button plugin without extending "engine" class. This PR is definitely a step in the right direction, but it needs some more love. |
I have a use case wherein I would like to be able to slap drupal-entity tags into my CKEditor, but without using Entity Embed's UI at all, and without its button(s) appearing in the editor.
This PR decouples the "engine" part of Entity Embed -- i.e., the widget definition -- from the UI and command parts. They are split into two separate JS files -- engine.js and plugin.js -- and two separate plugins on the Drupal side (drupalentity and drupalentity_button).